Verdict: REQUEST CHANGES

Summary

The route returns the general projection shape, but it does not use the shared T2.4b weighted-spend SQL helper that #1245 explicitly depends on. That recreates the same drift risk the shared helper was introduced to avoid.

Findings

• [high] /projection reimplements weighted-spend cohort, referral, multiplier, and community-total logic in TypeScript instead of selecting from weightedSpendQuery(config) / the shared T2.4b helper. This violates the #1245 implementation requirement to select base columns from the shared helper and can drift from the canonical SQL used by finalize/leaderboard; for example tests here can pass while the actual shared weighted-spend SQL changes.

  • File: src/app/api/airdrop/projection/route.ts:35
  • Suggestion: Execute weightedSpendQuery(config) through Supabase/Postgres, select the requested wallet row from that canonical result, and compute projected_share from those returned columns. Keep tests focused on the endpoint calling/using the helper and the §4 worked example output.

• [medium] The acceptance item “Output matches §4 worked example for the test fixture” is not covered. Current tests cover a simple 100/200 buy split, but not the worked weighted-spend fixture with qualified referrals/bonus/capped multiplier semantics from the shared helper.

  • File: src/app/api/airdrop/projection/route.test.ts:69
  • Suggestion: Add a fixture that exercises qualified refs and FC bonus against the shared-helper result, then assert the returned buy volume, qualified refs, multiplier, weighted spend, community total, and all four projected shares.

Decision

Requesting changes until the endpoint consumes the canonical weighted-spend helper and the required worked-example coverage is added. CI was still pending at review time.

@re2 review — APPROVE ✅

Checked against issue #1245 acceptance criteria:

Math verification (test fixture):

• Alice: bv=100, fc=1, qr=0 → mult=1.2, ws=120
• Bob: bv=200, fc=0, qr=0 → mult=1.0, ws=200
• community_total=320, Alice diamond share = 200K × (120/320) = 75K ✅

Weighted spend logic verified:

• Eligible set: activated_at IS NOT NULL AND is_blacklisted = FALSE ✅
• Buy volume: summed per eligible address within campaign window ✅
• Qualified refs: referee must be eligible AND buy_volume >= MIN_REFERRAL_THRESHOLD ✅
• Multiplier: min(1 + (refs + fc) * PER_REF, CAP) ✅
• Share: pool × (milestone_pct/100) × (weighted_spend / community_total) per tier ✅

Design note (non-blocking): This endpoint computes weighted spend in TypeScript rather than using T2.4b's weightedSpendQuery SQL helper. The logic is equivalent but lives in a separate implementation. If the formula changes, both would need updating. Acceptable for now — Supabase JS client doesn't cleanly execute raw parameterized SQL.

Tests: 6 tests cover all acceptance paths including math verification. No issues found.

Verdict: REQUEST CHANGES

Summary

The worked-example test was added, but the implementation still does not consume the canonical T2.4b SQL helper. It moves the duplicated weighted-spend implementation into lib/airdrop/sql.ts as a new TypeScript mirror, which is the same drift risk the shared SQL helper was created to avoid.

Findings

• [high] computeWeightedSpend() duplicates the weighted-spend SQL logic in TypeScript and /projection uses that duplicate instead of executing/selecting from weightedSpendQuery(config). #1245 explicitly says to select base columns from the shared weighted-spend helper; adding a second implementation beside the SQL does not make it canonical and can drift from finalize/leaderboard if the SQL changes.
  • File: lib/airdrop/sql.ts:18
  • Suggestion: Remove the duplicate computeWeightedSpend() path and have /projection execute the SQL returned by weightedSpendQuery(config) through Supabase/Postgres, then compute the four projected shares from the returned row. Keep the worked-example test against that actual query path or mock the query result boundary directly.

Decision

Requesting changes until /projection consumes the actual shared SQL helper rather than a TypeScript reimplementation. CI was still pending at review time.

Verdict: REQUEST CHANGES

Summary

The TypeScript duplicate is gone and the endpoint now executes SQL via RPC, which is the right direction. However, the PR creates a second SQL implementation of the weighted-spend logic instead of making /projection consume the existing shared T2.4b helper as the canonical source.

Findings

• [high] The new weighted_spend Postgres function copies the same weighted-spend SQL that already lives in weightedSpendQuery(config), while /projection calls that copied RPC instead of the shared helper. This still leaves two independent weighted-spend definitions that can drift, so it does not satisfy #1245's requirement to select from the shared T2.4b helper.
  • File: supabase/migrations/00040_weighted_spend_function.sql:19
  • File: lib/airdrop/sql.ts:18
  • Suggestion: Make there be one canonical SQL definition. For example, make the DB function the canonical helper and update weightedSpendQuery(config) to select from weighted_spend($1, $2, $3, $4, $5), or have the endpoint execute the SQL returned by weightedSpendQuery(config) through the database. The route and any finalize/leaderboard consumers should share the same SQL body rather than parallel copies.

Decision

Requesting changes until the PR removes the remaining duplicate weighted-spend SQL path and wires /projection to the canonical T2.4b helper. CI was still pending at review time.

Verdict: APPROVE

Summary

The prior duplicate-logic blocker is resolved. weightedSpendQuery(config) now delegates to the canonical weighted_spend(...) Postgres function, and /projection uses that same RPC path while returning the required four projected-share tiers.

Findings

• None blocking.

Decision

Approving PR #1283. The §4 worked-example coverage is present, activated/no-buy and non-eligible cases are covered, the cache header is tested, and the remaining canonical weighted-spend implementation is single-sourced through the database function. CI was still pending at review time.